-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Experimental stackmapping changes for Gen2 #1593
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: b168169 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR is missing tests.
/** | ||
* ExperimentalStackMapping override the assigned nested stack on a per-resource basis. Only applies to resolvers, and takes the form | ||
* { <logicalId>: <stackName> } | ||
*/ | ||
experimentalStackMapping?: Record<string, string>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have not yet finalized a method to expose experimental APIs so please hold with this change.
@@ -239,6 +239,7 @@ class DataGenerator implements ConstructContainerEntryGenerator { | |||
authorizationModes, | |||
outputStorageStrategy: this.outputStorageStrategy, | |||
functionNameMap, | |||
stackMappings: this.props.experimentalStackMapping, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this experimental
if it's mapping to construct property that is not experimental in underlying construct ?
It's just fixing important migration blocker issue #2550. Edit: It's suppressing gen 2 cli sandbox or production limit error, but in the otherside it's giving limit error on Cloudformation, I added 200 Custom mapping to 15 different stack, it's still giving limit error on Cloudformation, We have to declare ManyToMany fields manually on Gen 2, it's creating much resources compared to gen 1, But I did some much custom stack mapping still got no luck to fix limit error. |
@@ -30,6 +30,7 @@ export type DataProps = { | |||
name?: string; | |||
authorizationModes?: AuthorizationModes; | |||
functions?: Record<string, ConstructFactory<AmplifyFunction>>; | |||
experimentalStackMapping?: Record<string, string>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's review the API design internally. We may need a consolidated attribute to configure experimental features.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just works like gen1. It was working property on Gen 1. Now it can be usable on Gen 2. I don't know if it's experimental or not for this reason but it's works on Cloudformation same as gen 1.
But changing stacks with gen 1 or gen 2 not effecting resource limit on Cloudformation. These are still hits the resource limit
Co-authored-by: Kamil Sobol <[email protected]>
* feed pr base sha and ref into envs before scripts * removing empty file
PTAL, we need this |
Problem
Enabled the stack mapping property in Gen2
Issue number, if available:
aws-amplify/amplify-category-api#2550
Corresponding docs PR, if applicable:
Validation
Checklist
run-e2e
label set.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.